---
title: 'Infrastructure'
sidebarTitle: 'Infrastructure'
description: 'Learn more about the infrastructure of Nango.'
---

### Architecture diagram

<Frame caption="Nango's infrastructure components">
  <img src="/images/diagrams/nango-architecture.png" />
</Frame>

### Infrastructure components

Nango consists of several core services, each handling specific responsibilities:

- **Server (Node service)**: Powers the dashboard, API, proxy requests, and incoming/outgoing webhooks.
- **Orchestrator (Node service)**: Manages task scheduling and state tracking.
- **Jobs (Node service)**: Processes tasks and dispatches them to the Runner.
- **Runner (Node service)**: Executes integration code and interacts with external APIs.
- **Persist (Node service)**: Stores synced records and logs.
- **Postgres**: Stores data for the control plane, API credentials, scheduled tasks, and synced records.
- **Object Storage (e.g. S3)**: Stores compiled integration code for execution by the Runner.
- **ElasticSearch**: Stores execution data.
- **Redis**: Caches system data, including socket information, token refresh locks, and rate limits.

### Cloud vs. self-hosted architecture

The Nango architecture is largely the same for both Cloud and [Enterprise self-hosting](/guides/self-hosting/enterprise-self-hosting). This ensures self-hosted instances benefit from continuous dogfooding and load testing.

The primary differences are:
- In the Cloud version, the Runner service runs as isolated instances per customer.
- The Postgres database is segmented by use case (control plane, task scheduling, synced records).

### Email service

Nango uses emails for account verification, password reset, and sending invitations, etc...

Any SMTP server can be configured to be used by Nango for these email communications.

<Tip>
**Questions, problems, feedback?** Please reach out in the [Slack community](https://nango.dev/slack).
</Tip>